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ABSTRACT 

Often  the  process  and  effort  in  building  interoperable 
Command  and  Control  (C2)  systems  and  simulations  can 
be  arduous.  Invariably  the  difficulty  is  in  understanding 
what  is  intended.  This  paper  introduces  the  notion  of  com- 
posable  bridges  as  a  means  to  help  transition  abstract 
ideas  or  concepts  into  concrete  implementations. 

We  examine  the  key  elements  to  achieve  composabil- 
ity,  which  include  the  direction  provided  by  a  process,  the 
importance  of  a  conceptual  model,  the  use  of  patterns  to 
help  characterize  reusable  aspects  of  a  design,  the  impor¬ 
tance  of  having  good  discovery  metadata  and  well-defined 
interfaces  that  can  be  implemented,  the  use  of  components, 
and  the  practical  use  of  libraries  and  tools.  We  suggest 
that,  of  all  these  elements,  a  properly  documented  concep¬ 
tual  model  provides  the  basis  for  formulating  a  compos- 
able  bridge,  and  that  things  like  patterns,  discovery  meta¬ 
data,  and  interfaces  play  a  key  role.  We  take  a  look  at  a 
specific  standard  known  as  the  Base  Object  Model  (BOM) 
and  examine  how  it  provides  a  means  to  define  a  compos- 
able  bridge.  We  explore  how  BOMs,  in  this  capacity,  can 
be  aggregated  and  used  (and  reused)  to  support  the  crea¬ 
tion  of  concrete  implementations.  We  also  explore  how 
such  composability  helps  to  achieve  various  levels  of  inter¬ 
operability  for  C2  systems  and  Simulation  applications. 

1  INTRODUCTION 


Whether  we  are  architects,  develop¬ 
ers,  analysts,  educators,  or  managers, 
composability  is  a  common  shared 
desire.  There  is  a  consistent  need  to 
assemble  capabilities  and  develop 
meaningful  functionality  from  the 
knowledge,  tools,  standards  and 
components  that  are  available  to  us. 

Often  this  desire  to  create 
and  compose  is  a  trait  we  have  had 
since  we  were  young  (see  Figure  1). 

And  for  many,  it  has  never  left  us. 

We  have  simply  transferred  this  early  desire  to  the  context 
of  our  work  as  we  pursue  the  creation  of  innovative  things 


such  as  developing  and  integrating  models,  software  appli¬ 
cations,  simulations,  and  C2  systems. 

Composability  is  defined  by  the  DoD  M&S  Master 
Plan  as  “the  ability  to  rapidly  select  and  assemble  compo¬ 
nents  to  construct  meaningful  systems  to  satisfy  specific 
user  requirements.” 

There  are  three  aspects  of  composability  that  this  defi¬ 
nition  identifies: 

(1)  The  selection  and  use  of  components 

(2)  The  construction  of  meaningful  systems,  and 

(3)  The  satisfaction  of  specific  user  requirements 
We  will  briefly  explore  each  of  these. 

1.1  The  Selection  and  Use  of  Components 

This  first  aspect  of  composability  can  be  compared  to  the 
Lego®  mindset  as  illustrated  in  Figure  2  in  which  blocks 
selected  from  the  same  source  (i.e.,  Lego®  bins)  can  be 
used  and  reused  to  construct  various  creations.  The  Lego® 
bricks  serve  as  components. 


Figure  2.  Composability  Represented 
Using  Lego®  Bricks 


Although  the  construction  of  a  boat  or  car  using  Lego® 
bricks  may  be  more  trivial  than  perhaps  the  composability 
of  C2  systems  and  simulations,  what  is  congruous  is  sim¬ 
ply  the  idea  and  desire  to  select  and  use  components  in 
building  up  C2  systems  and  simulations. 

1.2  The  Construction  of  Meaningful  Applications 

Composability  begins  as  an  “idea”  in  the  conceptual 
space.  For  a  child,  such  ideas  start  as  a  glimmer  in  the 
mind’s  eye;  a  mental  picture  of  something  that  they  could 
potentially  create  from  the  bricks  that  lie  in  front  of  them. 


Figure  1.  An 
Illustration  of 
Composability 
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The  bricks  are  only  an  enabler,  the  fuel,  for  bringing  to 
life  what  starts  out  in  the  imagination.  However,  during 
the  process  of  building  they  may  continue  to  formulate 
their  concept  mentally,  until,  at  last,  a  meaningful  physical 
creation  is  complete.  This  is  where  the  chasm  is  crossed 
from  the  original  concept  to  the  first  implementation;  when 
an  idea  has  finally  become  something  real  and  tangible. 
The  question  that  is  asked  though  is,  “Does  it  satisfy  what 
was  intended?” 

1.3  The  Satisfaction  of  Specific  User  Requirements 

Once  a  Lego®  composition  is  complete,  a  child  will  typi¬ 
cally  revel  in  their  creation.  Eyeing  it  as  if  it  were  a  prize; 
satisfied  in  what  they  have  built  BUT  only  if  it  meets  what 
they  desired.  In  the  workplace  these  desires  are  better 
known  as  user  requirements.  And  they  may  start  as  objec¬ 
tives  and  ideas  formulated  initially  on  paper  as  require¬ 
ments,  then  spun  and  expanded  as  concept  diagrams  drawn 
up  on  paper,  within  a  tool,  or  on  a  white  board.  And  if  the 
passion  and  drive  are  there,  they  are  churned  and  worked 
until  a  satisfying  product  is  conceived,  whether  it  be  a 
software  application,  a  PowerPoint,  a  proposal,  or  new  sys¬ 
tem  or  simulation.  But  what  we  create  truly  isn’t  satisfying 
unless  it  has  met  our  requirements. 

Thus,  there  is  a  point  for  any  successful  project  where 
what  has  been  implemented  is  compared  to  what  was  con¬ 
ceptualized.  Consider  the  questions  that  are  pondered  at 
the  conclusion  of  a  project,  especially  large  projects: 

■  How  did  it  go? 

■  Did  we  meet  all  our  requirements? 

■  Was  the  sponsor  happy  with  the  results? 

It’s  intriguing  isn’t  it  that  we  often  wait  to  ask  these 
questions  until  after  a  project  is  completed?  This  may  be  a 
telltale  sign  that  that  those  involved  in  the  project  are  per¬ 
haps  not  communicating  early  and  often  enough  regarding 
what  is  intended  (i.e.,  the  concepts)  and  they  are  not  sub¬ 
sequently  correlating  those  intentions  with  what  they  are 
building  or  using  (e.g.,  components)  in  their  effort  to  real¬ 
ize  an  implementation.  What  is  needed,  therefore,  is  a 
means  to  assist  in  bridging  well  defined  concepts  with 
what  is  ultimately  being  implemented.  Considering  that 
the  process  and  effort  in  building  interoperable  C2  systems 
and  simulations  can  be  arduous,  this  need  for  bridging  the 
conceptual  plane  to  the  implementation  plane  through 
composability  is  significant. 

2  FORMULATING  COMPOSABLE  BRIDGES 

Typically,  a  bridge  is  defined  as  “a  structure  spanning  and 
providing  passage  over  a  gap  or  barrier.”  In  music  it  is  de¬ 
fined  as  “a  transitional  passage  connecting  two  subjects  or 
movements.”[l]  And  in  the  context  of  development,  a 
bridge  should  be  defined  as  “a  means  to  span  and  provide  a 


way  to  connect  an  idea  (i.e.,  initial  concept)  to  something 
implementable.”  This  idea  is  conveyed  in  Figure  3. 


Figure  3.  The  Development  Bridge 

For  projects  that  fail,  it’s  easy  to  determine  that  a 
bridge  encouraging  communication  among  stakeholders 
was  never  properly  formulated.  It  fell  short.  But  for  pro¬ 
jects  that  succeed,  a  bridge  is  formed,  which  makes  the 
journey  however  long  or  short,  possible  to  bare.  In  fact, 
what  we  all  want  for  any  project  is  to  be  able  to  bridge 
quickly  and  easily  from  initial  concept  to  implementation. 
The  question  is  how  can  that  best  be  done? 

What  if  such  bridges  could  be  reflected  structurally  as 
means  to  convey  a  concept  that  can  be  mapped  to  one  or 
more  potential  implementations?  Like  a  blueprint  to  a 
house  or  building?  What  if  the  common  desired  behaviors, 
understood  first  conceptually,  could  be  individually  de¬ 
fined,  described  and  cataloged  providing  a  means  to  assist 
in  communicating  an  idea  that  can  be  bridged  to  something 
implementable?  And  what  if  such  bridges  could  be  reused 
and  aggregated  to  formulate  the  scaffolding  needed  for  lar¬ 
ger  project  specific  bridges?  Wouldn’t  such  use  of  bridges 
increase  our  likelihood  for  effective  communication  among 
stakeholders  and  for  achieving  successful  creation  of 
meaningful  applications? 

2.1  Why  the  Conceptual  Model  is  Key 

We  postulate  that  the  conceptual  model  provides  the  basis 
for  a  composable  bridge.  The  conceptual  model  is  key  be¬ 
cause  it  is  intended  to  describe  “what  the  [system  or  simu¬ 
lation]  will  represent,  the  assumptions  limiting  those  repre¬ 
sentations,  and  other  capabilities  needed  to  satisfy  the 
user’s  requirements.” [5] 

Think  about  what  is  intended  to  be  offered  by  a  con¬ 
ceptual  model.  It  is  a  means  to  understand  what  is  to  be 
represented.  It’s  not  revealing  a  finished  product  -  but  it’s 
a  way  to  get  a  quick  look  at  what  that  product  might  be 
like;  much  like  a  blueprint  or  house  plan  is  to  a  prospective 
buyer.  Conceptual  models  offer  a  mechanism  for  commu¬ 
nication! 

Because  a  conceptual  model  is  implementation  neu¬ 
tral,  C2  systems  and  simulations  can  share  the  same  (or 
very  similar)  conceptual  models.  Capabilities  can  be  de¬ 
scribed  independent  of  whether  those  capabilities  are  real¬ 
ized  as  system  component  or  simulation  component. 
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We  also  recognize  that  C2  systems  including  applica¬ 
tions  and  web  services  may  embed  simulations  to  support 
its  objectives.  Such  C2  system/applications/web  services 
will  need  to  leverage  simulations  and  ’’compose”  services 
for  specific  C2/Simulation  needs  such  as  training.  Thus, 
the  need  for  composable  bridges  supported  through  well- 
defined  conceptual  models  can  be  of  great  assistance  here 
too. 

2.2  Fitting  the  Conceptual  Model  to  your  Process 

There  are  many  forms  that  conceptual  models  take  today 
across  the  various  disciplines  where  they  are  needed.  They 
maybe  captured  in  white  papers,  software  prototypes,  story 
boards,  or  other  related  artifacts.  This  said,  up  until  now, 
there  has  been  little  support  to  realize  these  prototypes  in 
respect  to  C2  systems  and  simulation  systems  and  to  ex¬ 
periment  and  exercise  with  them  at  a  conceptual  /  pre- 
decisional  level.  There  are  two  potential  reasons  for  this: 

1.  The  tools  and  standards  (including  architectures) 
have  either  been  non-existent  or  non-intuitive  too 
encourage  and  support  conceptual  modeling  for 
the  C2  system  and  simulation  domain,  or 

2.  The  time  required  to  perform  conceptual  model¬ 
ing  is  simply  not  allotted  by  stakeholders  within 
the  C2  system  and  simulation  domain. 

Both  these  reasons  have  merit,  but  perhaps  the  most  pre¬ 
cious  resource  available  to  any  of  is  time.  And  there  is  a 
perception  that,  because  of  schedule,  because  of  deadlines, 
because  of  time,  it’s  often  best  to  move  quickly  from  re¬ 
quirements  to  development  spending  little  time  performing 
the  analysis.  For  example,  If  you  examine  the  typical  de¬ 
velopment  effort,  there  are  a  few  interesting  tendencies  that 
we  see  take  place. 

(1)  First  Action  -  if  if  s  a  brand  new  project  or  even 
one  were  something  is  being  modified  -  a  con¬ 
certed  effort  is  often  made  to  identify  the  re¬ 
quirements.  It  might  start  by  asking,  “What  do  we 
want  the  system(s)  or  simulation(s)  to  do?” 
Whether  those  requirements  are  identified  as  a 
bullet  list  or  within  a  formal  specification,  the 
end-result  would  be  some  level  of  understanding 
of  the  requirements. 

(2)  Second  Action  -  once  funding  is  in  place  and  the 
requirements  identified  -a  team  of  engineers  and 
developers  typically  jump  in  and  begin  to  design, 
code  and  configure  system(s)  and  simulation(s)  to 
meet  the  stated  requirements  -  or  at  least  to  an 
engineers  understanding  of  the  requirements. 

(3)  Third  Action  -  Following  the  development  and  in¬ 
tegration  effort  a  series  of  tests  might  be  pre¬ 
formed  to  see  how  the  system(s)  or  simulation(s) 
measure  against  a  set  of  test  criteria  -  and  invaria¬ 
bly  that  test  criteria  is  based  on  the  requirements. 


We  could  spend  a  great  amount  of  time  drilling  into  any  of 
these  three  action  tendencies,  but  there’s  one  activity  that  is 
routinely  missed  following  the  First  Action  and  prior  to  the 
Second  Action.  An  activity  that,  if  missed  as  it  often  is, 
can  significantly  impair  the  success  of  the  other  actions 
we’ve  identified. 

The  activity  that  is  often  missed  is  the  development  of 
conceptual  models.  And  yet,  well  defined  processes,  like 
the  IEEE  Federation  Development  and  Execution  Process 
(FEDEP)  process  partially  illustrated  in  Figure  4,  identify 
the  importance  of  this  activity.  In  Figure  4  it  is  identified  as 
“conceptual  analysis”.  Conceptual  analysis  results  in  the 
production  of  conceptual  models.  These  conceptual  mod¬ 
els  provide  a  supporting  plan  to  fulfill  the  requirements 
that  were  identified  in  Step  1,  and  provide  a  means  to  guide 
the  rest  of  the  process  effort  -  like  a  blueprint. 


Figure  4.  Common  Development  Process 

Interestingly  enough  this  step  is  the  most  common  de¬ 
velopment  issue  for  a  development  team  [2].  Specifically, 
most  development  and  engineering  teams  completely  miss 
Step  2  of  the  process  identified  in  Figure  4.  The  impact  of 
missing  Step  2  is  that  it  often  results  in  miscommunication 
and  misunderstanding  among  stakeholders,  limiting  the 
success  of  a  project. 

It’s  like  a  house  being  built  solely  based  on  the  list  of 
features  a  home  owner  wants.  The  detailed  house  plan, 
aka  the  blueprint,  is  forgone.  Imagine  the  difficulty  a 
team  of  carpenters  might  have  in  trying  to  frame  and  build 
the  house.  Imagine  the  future  home  owner  feeling  as  if 
he’s  in  the  dark  until  the  structure  is  revealed  to  him. 
Imagine  the  dialog  that  might  take  place  between  the  home 
owner  and  the  contractor’s  team  when  the  home  under 
construction  does  not  match  exactly  what  the  home  owner 
wanted.  And  what  does  the  home  owner  have  as  a  record 
to  prove  to  anyone  that  the  contractor  is  not  implementing 
what  he  originally  desired.  That  is  why  a  blueprint  is  key. 

Like  the  development  of  a  blueprint,  Step  2’s  goal  is  to 
produce  conceptual  models.  Conceptual  models  identify 
what  needs  to  be  represented,  and  how  things  are  supposed 
to  behave.  And  like  a  blueprint,  it’s  this  artifact  that  helps 
bridge  the  communication  gap  between  multiple  stake¬ 
holders,  providing  a  common  framework  for  collaboration 
and  understanding.  Such  understanding  leads  to  proper 
composability,  and  therefore  better  software,  systems  and 
simulations. 

Additionally,  conceptual  models  should  be  leveraged 
throughout  development.  Like  a  blueprint,  we  need  to 
keep  coming  back  to  it,  because  it  ties  what  we  intend  to 
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build  (i.e.,  our  objectives),  with  what  we  are  designing  and 
developing.  It  creates  a  bridge. 

Consider  this,  if  the  conceptual  model  is  not  carried 
forward  -  applied,  understood,  visualized,  and  used  at  the 
various  stages  of  development  -  then  how  will  it  be  known 
that  the  objectives  have  been  met  and  satisfied? 

2.3  Discovering  Patterns 

A  question  to  ask  is,  “what  should  we  look  for  when  trying 
to  identify  and  define  conceptual  models?”  This  is  where 
patterns  come  into  play.  Patterns  offer  a  solution  that  can 
be  reused  for  supporting  a  common  problem  or  need.  They 
can  be  a  key  aspect  of  our  conceptual  model.  Martin  Fow¬ 
ler,  a  noted  Computer  Scientist,  describes  patterns  as  “an 
idea  that  has  been  useful  in  one  practical  context  and  will 
probably  be  useful  in  others.” 

Christopher  Alexander,  a  noted  author  and  professor, 
first  pioneered  the  concept  of  patterns  years  ago  when  he 
focused  on  aspects  for  improving  upon  the  way  building 
projects  are  designed  and  engineered.  In  his  landmark  book 
titled  “The  Timeless  Way  of  Building”  he  describes  the 
concept  as  follows: 

“ Each  pattern  describes  a  problem  which  occurs 
over  and  over  again  in  our  environment,  and 
then  describes  the  core  of  the  solution  to  that 
problem,  in  such  a  way  that  you  can  use  this  so¬ 
lution  a  million  times  over,  without  ever  doing  it 
the  same  way  twice .  ” 

His  work  is  a  reflection  of  what  some  of  the  quality 
architects  do;  they  look  for  patterns  when  designing  new 
projects.  Specifically  they  examine  the  requirements  that 
have  been  identified  and  then  draw  from  a  familiar  set  of 
patterns  that  they’re  experienced  with  and  propose  a  con¬ 
cept  that  satisfies  the  objectives.  Consider  that  a  blueprint 
to  a  future  house  reflects  many  common  patterns  and  yet, 
as  an  aggregate,  it  is  a  very  unique  design. 

The  software  engineering  realm  has  also  begun  to  em¬ 
brace  Alexander’s  pattern  concept.  Software  engineering 
patterns  are  being  applied  to  support  analysis,  design  and 
aid  in  refactoring  software.  Likewise,  we  have  the  same 
opportunity  for  applying  patterns  within  the  C2  systems 
and  simulations  arena.  By  focusing  on  reusable  patterns, 
we  can  achieve  a  higher  return  on  investment  allowing  sys¬ 
tems  and  simulations  to  be  more  easily  developed,  inte¬ 
grated  and  used. 

There  are  two  fundamental  types  of  patterns  that  can 
be  applied:  structural  patterns,  and  behavioral  patterns. 

■  A  structural  pattern  is  something  that  reflects  a 
common  object  or  combined  set  of  elements  re¬ 
vealed  within  an  environment.  We  might  identify 
a  structural  pattern  as  an  abstract  entity  like  an 
aircraft,  ground  vehicle,  radar  or  environmental 
feature  such  as  a  bridge  and  with  each  one,  iden¬ 


tify  common  attributes  among  these  abstract  enti¬ 
ties. 

■  A  behavioral  pattern,  on  the  other  hand,  is  some¬ 
thing,  that  reflects  the  anticipated  actions  and  var¬ 
iations  that  may  occur,  or,  perhaps  common 
events  or  various  states  of  an  entity,  which  can  be 
recognized  and  reproduced.  Some  common  be¬ 
havioral  patterns  that  are  employed  within  mili¬ 
tary  scenarios  are  depicted  in  Figures  5  and  6. 
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Figure  5.  Weapon’s  Effect 


Typically  patterns  are  discovered  rather  than  invented. 
In  this  example,  we  unveil  a  common  pattern  that  has  been 
reused  with  great  frequency  in  the  simulation  community. 
Two  entities  are  depicted.  One  that  fires  at  another.  Of 
interest  is  the  pattern  associated  to  this  Weapon’s  Effect 
behavior.  When  the  firing  entity  propels  an  ordnance  on 
the  target,  two  reciprocal  actions  will  typically  occur.  The 
Firing  Entity,  within  a  simulation,  will  then  update  the  po¬ 
sition  of  the  projectile  and  then  indicate  when  the  munition 
has  detonated.  And  then,  upon  detonation,  the  target  is 
then  responsible  for  sharing  its  damage  state  so  that  the  fir¬ 
ing  entity  is  aware  of  the  target’s  condition.  This  particu¬ 
lar  pattern  illustrated  in  Figure  5  is  also  decorated  with  the 
various  states  associated  to  each  type.  It  can  be  seen  how 
an  action  can  transition  a  state  change  upon  each  entity. 
This  aspect  of  States  of  an  entity,  which  is  known  as  a 
State  Machine,  is  also  a  key  aspect  of  an  executable  model. 
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(Originator)  Target 


Figure  6.  Jamming  /  Detection  Patterns 
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In  the  example  shown  in  Figure  6,  two  patterns  are  re¬ 
vealed.  We  could  conceivably  use  the  “Detection”  pattern 
for  other  purposes  besides  just  “Jamming”  such  as  “Vec¬ 
toring  Interceptors.”  What  we  learned  from  this  example  is 
that  the  best  way  to  discover  a  pattern  is  to  perform  some 
simple  analysis  on  the  problem  space  and  work  towards 
identifying  a  set  of  conceptual  models.  Otherwise,  rather 
than  two  patterns  being  revealed,  we  would  have  walked 
away  with  a  single  pattern  which  was  fairly  bulky,  special¬ 
ized,  with  limited  reuse. 

2.4  Identifying  Interfaces 

In  achieving  composability,  it  is  not  enough  to  discover 
and  document  patterns.  Step  3  of  the  FEDEP  process  ,  De¬ 
sign,  is  an  important  facet  to  the  development  effort.  A 
big  part  of  design  is  to  focus  on  the  “interface”  of  what  will 
be  provided  and  what  should  be  supported  by  an  imple¬ 
mentation  whether  that  resulting  implementation  be  a  piece 
of  hardware,  software,  or  a  service. 

Within  the  software  engineering  field,  and  supported 
within  the  C2  system  and  simulation  arena,  an  interface  is 
often  described  in  terms  of  class  structures  that  collectively 
define  the  inherent  capabilities  of  an  application,  compo¬ 
nent,  or  service. 

Bjames  Stroustrup,  who  was  responsible  for  the  crea¬ 
tion  of  the  C++  language,  shares  the  following  insight  re¬ 
garding  interfaces: 

“...it  is  essential  for  the  software  industry  rs  health 
that  key  interfaces  be  well-specified  and  publicly 
available.  ”  -  Bjarne  Stroustrup 

Interfaces  provide  a  contract  of  what  is  available  and 
accessible,  and  provides  a  framework  to  resulting  imple¬ 
mentations  (i.e.,  software  components,  simulations,  C2 
systems)  that  support  what’s  described  by  the  metadata  and 
defined  by  the  interface. 

2.5  Applying  Components 

Once  a  desired  interface  is  known,  the  logical  progression 
is  to  look  for  available  C2  system  and  simulation  compo¬ 
nents  that  support  the  conceptual  model.  If  candidate 
components  are  not  found,  then  the  framework  for  devel¬ 
oping  a  new  component  is  already  at  hand. 

The  DoD  M&S  composability  definition,  described 
previously,  referred  to  components.  Components  in  the  C2 
system  and  simulation  world,  of  course,  are  functionally 
different  than  a  Lego®  brick,  but  the  goal  is  the  same. 
Consider  the  definition  for  an  M&S  component. 

“ Reusable  building  blocks  which  have  a  known 
set  of  inputs  and  provide  expected  output  behav¬ 
ior,  but  the  implementation  details  may  be  hid¬ 


den.  Such  components  are  useful  for  construct¬ 
ing  simulations  and/or  providing  functionality 
for  simulation  systems.  ”  -  COI  M&S  Metadata 
Focus  Group 

The  unique  thing  with  a  Lego®  brick  is  that  it  is  clear 
how  to  snap  it  into  other  bricks.  The  inputs  and  expected 
outputs  are  known.  We  don’t  really  care  about  the  specific 
implementation  aspects  of  the  brick  itself;  whether  it’s 
plastic,  hollow,  or  solid.  But  we  do  care  about  function 
and  form  of  each  brick.  Therefore  we  look  for  a  brick  that 
satisfies  a  part  of  our  pattern,  and  can  adhere  to  our  inter¬ 
faces.  For  example  we  look  for  one  that  has  the  number  of 
nubs  that  we  desire  to  complete  some  portion  of  what  we 
intend  to  create.  When  the  brick  we  desire  is  found,  there 
should  be  enough  information  inherent  in  the  brick  for  us 
to  know  how  it  connects  with  other  bricks. 

We  recognize  that  Lego®  bricks  are  a  fairly  simplified 
example  of  composability.  In  other  words,  it  is  easy  to 
pick  up  a  brick  and  know  how  it  can  be  used.  Therefore, 
we  dare  not  trivialize  the  effort  associated  to  C2  system 
and  simulation  composability  as  being  as  simple  as  Lego® 
construction.  C2  system  and  simulation  components  don’t 
reflect  that  intuitiveness  that  Lego®  bricks  inherently  have. 
But  what  Lego®  bricks  and  C2  system  and  simulation 
components  do  share  in  common  is  that  the  inputs  and  out¬ 
put  of  a  component  should  be  known;  that  is  its  interface 
should  be  exposed.  This  allows  us  to  understand  the  build¬ 
ing  block  functionality  a  component  provides  in  potentially 
fulfilling  a  concept  or  objective.  In  this  way  a  component 
provides  a  means  to  satisfy  a  composable  bridge. 

2.6  Leveraging  Metadata 

Another  key  concept  to  help  optimize  composability  and 
reuse  is  to  ensure  the  discovery  of  useful  components.  If 
the  components  we  are  thumbing  through  aren’t  described 
in  a  manner  the  reveals  their  purpose  then  there  is  reason  to 
be  concerned.  Completing  the  bridge  from  concept  to  im¬ 
plementation  will  be  an  arduous  task. 

This  is  where  metadata  comes  into  play.  Metadata  is 
data  that  describes  other  data.  It  labels  and  describe  what 
something  is.  Metadata  is  formally  defined  as  follows: 

Metadata  is  structured ,  encoded  data  that  de¬ 
scribe  characteristics  of  information-bearing 
entities  to  aid  in  the  identification ,  discovery , 
assessment ,  and  management  of  the  described 
entities  [2].  ” 

In  order  to  leverage  a  toolbox  of  components  that  we  can 
compose,  it  is  necessary  to  use  metadata  to  catalog  (i.e. 
properly  label)  the  conceptual  model  (patterns)  and  inter¬ 
faces  that  reflect  these  available  components. 
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3  PUTTING  IT  ALL  TOGETHER 


Figure  7  provides  a  graphical  summarization  of  the  key 
concepts  we  have  identified. 


Figure  7.  Summary  of  Key  Concepts 

To  understand  this  graphic,  consider  the  following  nar¬ 
rative.  In  most  simulation  environments  today,  software 
produced  from  our  process  is  supported  by  tools  and  is  of¬ 
ten  maintained  in  libraries.  Users  of  such  tools  build  soft¬ 
ware  assets  and  access  and  manage  software  assets  via  li¬ 
braries.  These  tools  also  help  us  leverage  the  various 
software  assets  to  compose  new  applications  /  capabilities. 

What  is  often  lacking  is  the  metadata  and  conceptual 
models,  which  provide  a  thumbnail  sketch  to  catalog  and 
describe  the  anticipated  behavior  which  is  behind  such 
software,  system  or  simulation  assets.  Interfaces  are  also 
needed  to  properly  reuse  and  integrate  such  software,  sys¬ 
tem  and  simulation  assets  (i.e.,  components).  The  ability 
to  map  between  conceptual  models  and  the  various  inter¬ 
faces  provides  a  means  to  carry  forward  our  conceptual 
model  in  software  thereby  increasing  the  likelihood  of  it 
being  reused  to  support  composability. 

This  thumbnail  of  capability,  composed  of  the 
combination  of  metadata,  patterns,  interfaces,  and  their 
mappings  helps  to  fulfill  the  core  objective  we  discussed 
earlier  of  defining  and  using  composable  bridges.  Bridges 
that  produce  a  blueprint  that  satisfies  the  identified  re¬ 
quirements  prior  to  implementation,  and  satisfies  a  plan 
needed  for  implementation.  The  question  now  is  simply  the 
following: 

What  common  structure  allows  us  to  represent 
composable  bridges  for  supporting  C2  system  and 
simulation  interoperability? 

Figure  7  identified  a  few  key  characteristics  that  we 
need,  which  can  help  answer  this  question,  they  include  the 
following: 

■  discovery  metadata, 

■  patterns, 

■  mappings  of  entity  and  events  used  for  a  pattern  to 


■  interfaces  that  describe  the  specific  class  struc¬ 
tures  of  what  will  be  modeled,  and  shared. 

But  collectively  what  does  this  all  entail? 

Well,  Christopher  Alexander,  who  fathered  the  con¬ 
cept  of  patterns  even  before  software,  system  and  simula¬ 
tions  were  even  an  item  of  interest,  expressed  the  following 
ideas  pertaining  to  desired  characteristics.  He  shares,  and 
we  paraphrase,  that  a  pattern  should  support  the  following 
characteristics: 

■  Identify  and  name  the  common  problems  in  a 
field  of  interest. 

■  Describe  the  key  characteristics  of  effective  solu¬ 
tions  for  meeting  some  stated  goal. 

■  Help  the  designer  move  from  problem  to  problem 
in  a  logical  way. 

■  Allow  for  many  different  paths  through  the  design 
process. 

These  characteristics  need  to  be  considered  when  iden¬ 
tifying  a  common  structure  to  represent  well  understood 
and  reusable  assets;  assets  which  are  intended  to  be  used  as 
means  to  formulate  reusable  and  composable  bridges, 
which  expedite  the  development  process. 

4  CHOOSING  A  COMMON  STRUCTURE  - 
THE  BOM 

One  standard  that  matches  well  with  Alexander’s  desired 
characteristics  of  a  pattern  is  the  Base  Object  Model 
(BOM)  standard.  The  BOM  is  a  recent  Simulation  Inter¬ 
operability  Standards  Organization  (SISO)  Standard  devel¬ 
oped  in  the  open  community  for  the  purpose  of  supporting 
composable  and  interoperable  object  modeling.  It  is  de¬ 
fined  as  “a  piece  part 
of  a  conceptual  model, 
simulation  object 
model,  or  federation 
object  model,  which 
can  be  used  as  a  build¬ 
ing  block  in  the  devel¬ 
opment  and/or  exten¬ 
sion  of  a  simulation  or 
federation.”  [3] 

The  idea  behind 
BOMs  can  be  traced 
back  to  the  mid  90s 
when  the  HLA  inter¬ 
operability  standard 
was  first  being  culti¬ 
vated.  It  was  then  that 
this  notion  of  a  piece 
part  concept  was  con¬ 
sidered  which  could 
serve  as  building  g 

blocks  in  respect  to  the  Jhe  B0M  Structure 

development  process 
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and  the  creation  of  interoperable  simulation  models  and 
system  components.  [4] 

The  conceptual  model  aspect  is  one  of  the  discrimina¬ 
tors  of  the  BOM;  one  of  the  things  that  sets  itself  apart. 
Prior  to  the  BOM  standard,  the  M&S  community  did  not 
have  a  formal  and  easy  way  to  describe  and  share  concep¬ 
tual  model  elements,  and  did  not  have  an  easy  way  to  carry 
that  conceptual  model  forward  through  the  development 
process. 

Figure  8  peers  under  the  hood  of  what  the  BOM  stan¬ 
dard  provides.  The  subsections  that  follow  dive  further 
into  the  BOM  structure  elements. 

4.1  Model  Identification 

The  first  and  foremost  piece  identified  in  Figure  8  is  the 
Model  Identification,  which  represents  the  essential  Dis¬ 
covery  Metadata.  Metadata  is  important  so  that  BOMs  can 
be  described,  discovered,  and  properly  reused.  Consider 
items  on  the  shelf  of  a  grocery  story.  If  a  label  wasn’t  on 
the  cans  of  food,  and  boxes  of  cereal  that  described  the 
contents,  then  that  food  resource  would  likely  not  be 
bought. 

The  important  thing  to  share  about  BOM  metadata  that 
it  offers  not  only  a  way  to  tag  and  “label”  resources  with 
vital  data  such  as  Points  of  Contact,  Description,  and  Ap¬ 
plication  Domain,  but  it  also  provides  a  way  to  collect  and 
share  feedback  usage  through  a  Use  History  element.  Con¬ 
sider  how  one  views  potential  books  and  products  of  inter¬ 
est  on  Amazon.com.  A  prospective  buyer  is  offered  the 
ability  to  read  about  the  experiences  of  other  readers  per¬ 
taining  to  the  book  or  product.  That  facet  of  metadata  is 
also  offered  through  the  model  identification  metadata 
piece  provided  by  the  BOM.  It  should  be  noted  that  this 
metadata  is  based  on  other  standards,  such  as  the  DDMS, 
Dublin  Core,  VV&A  Recommended  Practice  guide  (RPG), 
and  HLA,  resulting  in  a  well  structured  and  clean  means  to 
catalog  BOMs. 

4.2  Conceptual  Model  Definition 

The  BOM  also  offers  a  formal  way  to  capture  and  share  the 
Conceptual  Model.  As  stated  earlier,  a  conceptual  model 
provides  a  description  of  “what  is  to  represented,  the  as¬ 
sumptions  limiting  those  representations,  and  other  capa¬ 
bilities  needed  to  satisfy  the  user’s  requirements.” [5]  In 
regards  to  the  conceptual  model  what  can  be  reflected  is 
the  Pattern  of  Interplay,  the  States  of  an  entity,  the  entity 
types  and  event  types. 

This  idea  of  pattern  discovery  is  very  relevant.  A  Pat¬ 
tern  is  “an  idea  that  has  been  useful  in  one  practical  context 
and  will  probably  be  useful  in  others.”  [Martin  Fowler]. 
The  Weapon’s  Effect  pattern  shown  in  Figure  5  is  an  ex¬ 
ample  of  something  is  done  with  some  frequency  in  com¬ 
bat  simulations;  it  is  a  pattern.  This,  again,  is  the  differ¬ 


entiator  from  other  object  modeling  frameworks.  And  this 
aspect  is  important,  because  if  intent  can  be  understood  as 
well  as  the  anticipated  behavior,  then  it  is  easier  to  know 
how  to  reuse  something.  The  conceptual  model  forms  the 
basis  of  defining  a  reusable  bridge  component. 

4.3  Object  Model  Interface 

There  is  also  the  aspect  of  model  mapping,  which  will  be 
touched  on  in  a  moment.  But  first  it’s  important  to  examine 
the  Object  Model  Interface.  In  Figure  8,  the  first  thing 
that  may  be  seen  in  regards  to  the  Object  Model  Interface 
is  an  HLA  label  tethered  to  Object  Classes,  Interaction 
Classes  and  Data  Types.  Rightly  or  wrongly  there  is  often 
a  negative  or  positive  reaction  to  the  HLA  label.  But  it’s 
important  to  not  be  fooled  by  the  HLA  label.  BOMs  are 
not  restricted  to  HLA.  There  is  a  perfectly  good  explana¬ 
tion  of  why  this  is  here. 

It’s  important  to  first  explain  what  aspects  are  not 
HLA  about  the  Object  Model  Interface  of  the  BOM.  No¬ 
tice  what  is  not  identified  are  HLA  Dimensions,  HLA 
Time,  HLA  Tags,  HLA  Synchronizations,  HLA  Transpor¬ 
tations,  HLA  Switches  -  they  are  not  in  there  because  they 
were  not  seen  as  essential  to  document  a  BASE  object 
model. 

All  that  is  really  needed  at  the  object  modeling  level  is 
a  way  to  describe  data  structures  -  specifically  data  types, 
object  classes  and  the  types  of  interactions  that  stake¬ 
holders  need  represented.  HLA  simply  provided  the  most 
accepted  and  understood  class  structure  mechanism  for  de¬ 
scribing  data  types,  object  classes  and  interaction  classes 
and  that’s  why  it  is  reflected  by  the  BOM.  The  develop¬ 
ment  group  behind  this  standard  didn’t  want  to  re-invent 
something  that  was  already  sufficient  for  M&S  developers. 

4.4  Model  Mapping 

It  is  important  go  back  to  the  Model  Mapping  aspect.  This 
is  one  area  where  some  of  the  magic  happens.  The  focus 
here  is  that  the  ABSTRACT  things  described  in  a  Concep¬ 
tual  Model  (entities  and  events)  can  be  mapped  to  the  ac¬ 
tual  types  of  things  to  be  modeled  and  represented  by  a 
system  implementation  (i.e.  ,  a  C2  system  or  simulation 
component).  The  capabilities  of  these  components  are  de¬ 
scribed  in  the  Object  Model  Definition.  Thus,  if  a  firing 
entity  is  identified  at  the  conceptual  level  (in  the  concep¬ 
tual  model),  a  Model  Mapping  indicates  what  object 
classes  (or  interaction  classes)  will  fulfill  the  entities  and 
events  associated  to  it. 

Incidentally  it  needs  to  be  clearly  understood  that  a 
BOM  does  not  require  within  itself  both  Conceptual  Model 
Definitions  and  Object  Model  Interfaces.  Object  Model 
interfaces  can  be  described  within  other  BOMs.  Yes, 
mapping  can  be  made  across  one  or  more  BOMs,  FOMs  or 
other  architectures  models  (such  as  TENA)  defining 
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classes.  This  loose  coupling  capability  is  vary  important 
for  bringing  to  bare  composable  bridges  for  it  allows  rela¬ 
tionships  to  be  defined  that  can  be  easily  replaced. 

5  BOM  USE  CASE  EXAMPLES 

To  date  BOMs  have  been  formulated  and  used  to  doc¬ 
ument  and  communicate  the  conceptual  space  for  the  Ar¬ 
my,  Navy,  Air  Force,  Missile  Defense  Agency,  and  general 
simulation  community.  For  example,  JHU/APL  used 
BOMs  to  represent  a  synergistic  conceptual  model  of  the 
Airborne  Electronic  Attack  (AEA)  communications  archi¬ 
tecture  for  the  Air  Force.  Such  BOMs  were  developed 
from  the  collection  of  DoDAF  views  that  were  originally 
formulated  by  the  JHU/APL  architecture  team.  The  BOMs 
have  helped  to  solidify  mission  objectives  and  capabilities. 
Additionally,  a  mapping  of  the  AEA  conceptual  space  pro¬ 
vided  by  such  BOMs  is  being  made  using  to  the  software 
constructs  representing  JHU/APL’ s  simulation  environ¬ 
ment.  This  allows  for  effective  communication  and  trace- 
ability  in  the  composition  of  AEA  models. 

BOMs  have  also  recently  been  used  by  the  surface 
Navy  to  rapidly  prototype  and  explore  potential  Mid- 
Range  Ballistic  Attack  Munitions  (MR-BAM)  concepts. 
These  BOMs  provided  the  framework  for  a  resulting  proto¬ 
type  C2  system  component  or  simulation  was  allowing  it  to 
be  developed  and  demonstrated  within  a  very  short  period 
of  time. 

A  set  of  BOMs,  known  as  the  Real-time  Platform  Ref¬ 
erence  (RPR)  BOMs,  have  been  also  been  developed  for 
the  general  simulation  community.  These  BOMs  define 
building  block  components  of  what  had  been  historically  a 
monolithic  model  set  called  the  Real-time  Platform  Refer¬ 
ence  (RPR)  FOM.  By  breaking  the  RPR  FOM  into  a  set 
of  manageable  RPR  BOMs,  it  is  now  much  easier  to  cus¬ 
tomize  and  extend  specific  capability  in  respect  to  both  the 
simulations  and  the  FOMs  that  such  simulations  use  with 
requiring  significant  rework  and  testing.  This  facet  is  ex¬ 
plored  further  in  Section  6.3. 

6  THE  PURSUIT  OF  INTEROPERABILITY 

According  to  the  DoD  M&S  Master  Plan,  composabil- 
ity  is  necessary  to  enable  effective  integration ,  interopera¬ 
bility  and  reuse.  We  have  already  talked  about  integration 
provided  through  mapping  and  reuse  supported  through 
metadata,  but  it’s  time  to  complete  the  thought  and  discuss 
interoperability  especially  as  it  relates  to  C2  systems  and 
simulations.  Figure  9,  illustrates  two  aspects  of  compos- 
ability:  model  composability  and  system  composability. 
Thus  far  we  have  focused  our  attention  on  model  compos¬ 
ability,  which  involves  taking  an  idea  from  the  conceptual 
space  and  reaching  a  successful  implementation.  How¬ 
ever,  within  a  world  in  which  C2  systems  and  simulations 
must  interoperate,  there  is  another  facet  of  composability 


identified  as  system  composability  which  correlates  with 
the  idea  of  Interoperability. 
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Figure  9.  The  BOM  Structure 

It’s  simply  not  enough  to  claim  victory  once  the  implemen¬ 
tation  is  complete,  we  must  also  explore  how  such  an  im¬ 
plementation  can  integrate  with  other  implementations. 

6.1  Levels  of  Interoperability 

According  to  Tolk,  there  are  six  levels  of  interopera¬ 
bility  [6]  that  need  to  be  explored  and  pursued  to  achieve 
the  System  Composability  capability  desired.  These  levels 
of  interoperability  are  identified  in  Figure  10. 


Figure  10.  Tolk’s  Levels  of  Conceptual 
Interoperability  Model  (LCIM) 

It’s  important  to  understand  what  each  of  these  levels  of 
interoperability  entail: 

>  Level  1  -  Technical  Interoperability  requires  an 
agreed  upon  communication  technology  infrastructure 
and  protocols  such  as  UDP  or  TCP/IP  to  support  the 
handshaking  among  networked  systems. 
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>  Level  2  -  Syntactic  Interoperability  is  achieved  us¬ 
ing  technology  such  as  XML,  which  offers  a  means  to 
define  and  use  a  common  data  structure  among  the 
systems  established  in  a  network. 

>  Level  3  -  Semantic  Interoperability  is  achieved 
when  a  common  reference  model  (i.e.,  definition  set) 
is  used  to  perpetuate  the  understanding  of  the  level  2 
data  being  shared. 

>  Level  4  -  Pragmatic  Interoperability  is  achieved 
when  the  systems,  simulations  or  applications  in¬ 
volved  in  the  exchange  of  data  are  aware  of  the  spe¬ 
cific  methods  and/or  procedures  that  a  calling  system 
is  requesting. 

>  Level  5  -  Dynamic  Interoperability  is  achieved 
when  systems  are  able  to  come  “on-line”  and  begin  to 
exchange  and  reflect  data  with  other  systems.  Such 
systems  are  “able  to  comprehend  the  state  changes  that 
occur  in  the  assumptions  and  constraints  that  each  is 
making  over  time,  and  they  are  able  to  take  advantage 
of  those  changes. ”[7] 

>  Level  6  -  Conceptual  Interoperability  is  achieved 
when  the  anticipated  capability  that  is  to  be  provided 
by  the  models  and  simulations  to  be  used  are  fully  un¬ 
derstood  and  agreed  upon  by  all  the  stakeholders.  At 
this  level  of  interoperability  there  is  no  ambiguity  in 
what  is  expected  to  be  shared. 

We  could  spend  significant  time  further  discussing 
each  of  these  levels  of  interoperability,  and  the  standards 
the  are  available  to  support  each  level,  but  the  ability  to 
achieve  Level  6  Conceptual  Interoperability  is  what  en¬ 
sures  the  likelihood  of  success  at  any  of  the  other  lower  le¬ 
vels  of  interoperability.  According  to  Davis  what  is  re¬ 
quired  for  Level  6  interoperability  is  a  “fully  specified,  but 
implementation  independent  model. ”[8]  And  this  is  where 
the  recent  BOM  standard  can  be  applied. 

6.2  The  Role  of  Conceptual  Models  and  BOMs 

BOMs  can  be  used  to  represent  “piece  parts  of  a  con¬ 
ceptual  model  that  can  be  used  as  a  building  block  in  the 
development  and/or  extension  of  a  simulation  or  federa¬ 
tion.”  [9]  It  provides  a  candidate  standard  that  can  help 
achieve  the  interoperability  desired  from  Level  6  to  Level 
2  by  helping  focus  on: 

■  what  needs  to  be  shared  conceptually  within  an 
M&S  environment, 

■  how  the  intended  models  are  to  perform  pragmati¬ 
cally, 

■  how  qualifying  interfaces,  which  map  with  the 
conceptual  space,  are  semantically  defined,  and 

■  how  such  models  are  syntactically  structured  (i.e., 
it  provides  a  template). 

That  said,  it  should  be  noted  that  BOMs  are  not  in¬ 
tended  to  be  a  replacement  of  interoperability  exchange 
standards  like  DIS,  HLA  or  TENA.  On  the  contrary,  they 


are  instead  intended  to  complement  and  facilitate  the  use  of 
such  interoperability  standards  in  an  independent  way  - 
even  allowing  different  interoperability  exchange  standards 
to  co-exist  -  if  that  is  what  is  necessary. 

6.3  Common  Use  of  Object  Model  Interfaces 

Interoperability  standards  such  as  DIS,  HLA  and  TENA, 
while  serving  different  domains,  share  some  interesting 
characteristics.  Principally  the  use  of  Object  Models  is 
shared  by  the  HLA  and  TENA  communities.  Object  mod¬ 
els  offer  semantic  interoperability,  and  BOMs  provide  a 
common  object  modeling  mechanism  that  can  be  used 
across  different  interoperability  architectures.  [10] 

The  piece  part  /  building  block  concept  provided  by 
the  BOM  standard  offers  the  type  of  modularity  that  is 
needed  for  representing  C2  system  and  simulation  object 
models  and  facilitating  interoperability  of  C2  system  and 
simulations  -  regardless  of  what  exchange  standards  are 
applied  (e.g.,  DIS,  HLA  and  TENA). 

A  key  word  to  be  emphasized  is  the  word  “Base”  in 
Base  Object  Model.  A  BOM  serves  as  a  “Base”  in  several 
ways: 

1.  It  serves  as  an  interface  for  “Base-level”  compo¬ 
nents  that  can  be  constituted  with  other  base-level 
components.  BOMs  offer  foundational  pieces  that 
can  be  leveraged  as  a  basis  for  object  modeling. 
Like  selecting  components  off  a  palette,  BOMs 
can  be  selected  to  construct  object  models  of  si¬ 
mulations  and  federations.  Thus  the  idea  of  a 
building  block.  In  this  way  it  offers  a  flexible 
component  approach. 

2.  It  also  offers  the  “basic”  elements  needed  for  ob¬ 
ject  modeling.  In  a  very  simple  way  object  classes 
can  be  defined  with  their  supporting  attributes. 
Not  required  for  these  classes  are  the  things  that 
are  implementation  specific  such  as  dimensions 
and  routing  spaces,  which  is  used  for  HLA  but 
may  be  meaningless  for  other  interoperability  ar¬ 
chitectures  that  could  be  employed.  This  aspect  is 
very  important  from  the  perspective  of  Syntactic 
Interoperability,  and  this  will  be  explored  later. 

3.  Close  examination  of  Figure  5  reveals  a  weapons 
effect  pattern  that  can  be  captured  as  a  BOM  .  In 
this  pattern  example  one  entity  fires  a  munition  on 
a  target.  The  munition  detonates,  and  an  update 
regarding  the  damage  state  of  the  target  is  re¬ 
flected.  This  is  a  commonly  anticipated  behavior 
for  most  theater  warfare  exercises.  We  expect  to 
shoot  at  things  -  and  this  is  how  we  typically  do 
it.  Therefore  “base”  in  this  context  refers  to  “fun¬ 
damental  patterns  of  interplay.”  Such  patterns 
provide  the  basis  for  fulfilling  the  overall  objec¬ 
tives.  The  aggregate  of  these  objectives,  is  what 
is  seen  on  the  right  hand  side  of  Figure  11.  Each 
BOM  provides  a  “basis”  of  understanding  at  the 
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conceptual  model  level,  describing  the  fundamen¬ 
tal  behaviors  and  models  that  we  can  compose  in¬ 
to  providing  a  much  richer  model  set. 

6.4  Supporting  Different  Interoperability 
Architectures 


As  BOMs  are  stitched  together  it  results  in  something 
called  a  BOM  Assembly.  The  combination  of  BOMs 
spanning  both  conceptual  model  and  the  structural  ele¬ 
ments  offered  by  object  model  needed  of  a  C2  system  or 
simulation  can  be  selected,  connected,  and  coupled  to¬ 
gether  to  formulate  a  BOM  Assembly.  Through  the  use  of 
some  transformations  that  assembly  can  be  used  to  repre¬ 
sent  the  exchange  document  for  a  specific  interoperability 
architectures  such  as  an  HLA  Object  Model  or  a  TENA 
LROM  as  illustrated  in  Figure  11. 

The  benefit  of  this  type  of  mapping  using  BOMs  was 
shared  by  Cutts  and  Gustavson  at  the  I/ITSEC  2006  con¬ 
ference  in  Orlando,  Florida: 


“the  abstract  things  described  in  a  Conceptual  Mod¬ 
el  (entities  and  events)  can  be  mapped  to  the  actual 
types  of  things  we  are  modeling,  which  are  described 
in  the  Object  Model  Definition  of  a  BOM.  So,  if  I 
identify  that  there  is  a  firing  entity  at  the  conceptual 
level  (in  the  conceptual  model),  my  mapping  tells  me 
what  system  architecture  classes  [HLA,  TENA,  Navy 
OA  or  otherwise]  can  fulfill  the  entities  and  events 
associated  to  it.  ”  [10] 


In  this  way,  the  mapping  aspect  of  a  BOM  provides  a 
powerful  construct  for  representing  composable  bridges, 
because  it  spans  the  conceptual  space  with  the  implementa¬ 
tion  space. 


HLA 

Object  Model 


Figure  1 1 .  BOM  Assembly  applied  to 
Different  Interoperability  Architectures 


|  TSPI  | 
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7  GUIDANCE 

So  how  does  one  begin  to  build  and  use  highly  reusable  as¬ 
sets  that  help  bridge  the  conceptual  space  with  the  imple¬ 
mentation  space?  Again  it  all  starts  with  the  conceptual 
model,  which  needs  to  be  carried  forward  into  the  other 
products  that  are  built..  And  conceptual  models  describing 
C2  system  and  simulation  components  need  to  be  properly 
described  with  metadata,  and  mapped  so  that  appropriate 
building  blocks  and  supporting  C2  system  and  simulation 
components  can  be  identified  and  used.  This  is  best  ac¬ 
complished  with  iterative  /  incremental  approach.  Also 
known  as  a  spiral  model. 

And  as  patterns  are  being  discovered  and  described 
“Consider  what  should  be  variable  in  your  design”  and 
“encapsulate  the  concept  that  varies”  within  the  pattern. 
[11-  p.  29].  This  abstraction  effort  is  what  allows  greater 
reuse  and  value. 

Many  developers  and  engineers  learn  the  power  of 
class  inheritance,  and  some  begin  to  over  use  and  abuse 
this  extensible  methodology  supported  by  object  oriented 
languages.  However,  in  regards  to  reuse,  inheritance  can 
be  a  highly  limited  aspect.  What  is  recommended  instead 
are  for  engineers  to  “favor  object  composition  over  class 
inheritance”  especially  in  respect  to  conceptual  modeling 
[11  -  p.  20].  It  is  far  more  effective  in  regards  to  reuse  to 
define  a  class  that  “has  a”  an  attribute  of  another  class  than 
to  define  a  class  that  “is  a”  an  extension  of  another  class. 
The  “is  a”  relationship  provides  a  hard  dependency  and 
binding  on  another  class  which  can  limit  the  class  in  being 
affectively  used  by  others.  Whereas,  the  “has  a”  relation¬ 
ship  allows  a  class  to  couple  it  self  with  other  classes  in  a 
very  loose  and  flexible  way.  The  attributes  of  that  class 
which  associate  to  another  class,  can  adapt  to  other  classes 
being  used  with  out  affecting  the  class  for  which  the  attrib¬ 
ute  is  associated  to. 

Within  a  BOM  such  classes  are  defined  at  the  concep¬ 
tual  model  as  entities.  And  attributes  are  defined  as  char¬ 
acteristics.  Furthermore,  a  BOM  does  permit  inheritance  at 
the  Conceptual  Model  Definition  layer.  It  does,  however 
allow  for  inheritance  of  classes  that  are  being  defined 
within  the  Object  Model  interface  layer,  which  may  yield 
opportunities  for  appropriate  use  of  inheritance.  But  at  the 
conceptual  model  definition  layer,  it  is  neither  recom¬ 
mended  nor  feasible. 

Another  very  important  aspect  is  that  these  compos- 
able  bridges  that  are  build  and  use  (e.g,  a  BOMs)  should 
always  be  designed  to  an  interface  rather  an  implementa¬ 
tion.  [11  -  p  18].  It’s  important  to  ensure  separation  of 
interface  from  the  implementation.  Having  the  ability  to 
have  combosable  bridges  (e.g.  BOMs)  that  characterize 
capability  without  regard  to  platform  and  language,  and  an 
available  set  of  C2  system  and  simulation  components  that 
adhere  to  those  BOMs  and  fulfill  the  capability  for  my 
platform  and  language  of  choice  is  desirable.  It  provides 
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the  fuel  needed  to  bring  conceptual  ideas  to  life,  and  in  a 
composable  way. 

8  SUMMARY 

In  this  paper  we  address  interoperability  as  it  to  pertains  to 
C2  systems  and  simulations.  We  explored  how  such  inter¬ 
operability  can  be  addressed  through  "composability",  and 
suggest  that  composability  can  best  be  understood  and  car¬ 
ried  forward  through  the  use  of  "bridges"  that  “span  and 
provide  a  way  to  connect  an  idea  (i.e.,  concept)  to  some¬ 
thing  implementable.” 

We  have  identified  that  such  bridges  can  be  and 
should  be  represented  and  supported  by  well-defined  con¬ 
ceptual  models,  providing  an  effective  way  to  communi¬ 
cate  among  stakeholders. 

We  state  that  C2  systems  and  simulations  can  share 
the  same  (or  very  similar)  conceptual  models.  That,  be¬ 
cause  a  conceptual  model  is  implementation  neutral,  capa¬ 
bilities  can  be  described  independent  of  whether  those  ca¬ 
pabilities  are  realized  as  system  component  or  simulation 
component. 

We  also  recognize  that  C2  systems  including  applica¬ 
tions  and  web  services  may  embed  simulations  to  support 
its  objectives.  Such  C2  system/applications/web  services 
will  need  to  leverage  simulations  and  "compose"  services 
for  specific  C2/Simulation  needs  such  as  training.  Thus, 
the  need  for  composable  bridges  supported  through  well- 
defined  conceptual  models  can  be  of  great  assistance  here 
too. 

We  suggested  that  composable  bridges,  like  a  blue¬ 
print,  need  to  be  reflected  structurally  as  a  means  to  com¬ 
municate  a  concept  for  all  stakeholders.  We  suggested  that 
such  bridges  could  be  built  for  reuse  describing  common 
patterns,  which  can  then  be  mapped  to  one  or  more  poten¬ 
tial  implementations.  We  then  explored  the  aspects  of 
building  composable  bridges,  which  link  the  conceptual 
space  and  the  implementation  space.  The  goal  of  such 
bridges  is  to  help  bring  to  life  satisfying  interoperable  C2 
systems  and  simulations  quickly  and  easily. 

As  an  analogy  we  explored  the  art  of  composing 
Lego®  creations  in  how  it  relates  with  our  desires  within 
the  C2  and  simulation  interoperability.  We  have  stated 
that  the  difference  between  building  a  Lego®  creations  and 
an  C2  and  M&S  creations  is  the  complexity  of  what  is  in¬ 
tended,  and  have  recognized  that  the  clarity  provided  by  a 
conceptual  model  is  what  helps  bring  a  concept  to  imple¬ 
mentation  and  then  to  a  potential  state  of  interoperability. 
We  concluded  that  a  conceptual  model  provides  an  effec¬ 
tive  bridge  that  could  be  easily  reused  to  support  multiple 
projects  and  interoperability  efforts. 

As  an  enabling  technology,  we  explored  how  the 
BOM,  which  is  a  recent  SISO  standard,  offers  a  means  to 
define  and  share  composable  bridges.  That  it  offers  a 
component-based  standard  for  reflecting  conceptual  mod¬ 
els  and  linking  such  conceptual  models  to  implementable 


interfaces.  Interfaces  that  can  be  supported  by  a  variety  of 
architectures  including  various  software  languages  (C++, 
Java)  and  interoperability  standards  (HLA,  TENA,  DIS). 

The  BOM  provides  a  reflection  of  that  conceptual 
model,  which  can  be  used  in  several  ways: 

(1)  It  helps  identify  a  neutral  way  to  characterize  both  C2 
capabilities  and  simulation  capabilities. 

(2)  Next,  it  can  be  used  to  help  identify  existing  candidate 
C2  system  and  simulation  components  that  support 
specific  purposes  such  as  training  and  testing. 

(3)  If  eligible  C2  system  and  simulation  candidates. . . 

a.  cannot  be  found,  then  the  BOM  helps 
"bridge"  over  to  designing  the  capability 
that’s  needed. 

b.  can  be  found,  then  selections  can  made  with 
"mappings"  documented,  which  will  allow 
for  easier  reuse  /  integration  in  the  future. 

(4)  Additionally,  the  use  history  experience  can  be  high¬ 
lighted  back  into  the  BOM  (as  metadata),  making  it 
even  easier  for  sponsors,  developers  and  engineers  to 
select  and  choose  viable  C2  and  Simulation  compo¬ 
nents  in  the  future  that  they  want  to  integrate  into  their 
environment. 

We  recommend  that  a  standard  such  as  BOMs  be  used 
and  applied  as  a  common  framework  for  defining  and  shar¬ 
ing  composable  bridges,  which  facilitates  communication 
among  stakeholders  and  helps  realize  implementation 
needs  for  C2  systems  and  simulations. 
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-  Aspects  of  Process 

-  Aspects  of  Standards 
Definitions 

-  Bridge 

-  Conceptual  models 
Bridges  Built  for  Reuse 

-  Patterns 

-  Interfaces 

-  Components 

-  Discovery  Metadata 

Enabling  Technology  Standard  for  Composable  Bridges 
Using  BOM  as  a  Bridge  to  Achieve  Interoperability 
Summary 


Bridge 

-  Composable 

-  Adheres  to  Process 

-  Standards  Based 


• Implementation 
•C2/ Simulation 
interoperability 


BOM 

B^se  Object  Mo4ei 


Building  Composable  Bridges 
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Problem 
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•  Building  interoperable  C2  systems  and 
simulations  is  arduous 

•  Difficulty  is  in  understanding  what  is  intended 

•  Consider 

-  Why  Projects  Fail? 

-  Why  They  Succeed? 


Findings 

•  Lack  of  communication  among 
teams 

•  Not  correlating  intentions  with 
what  is  being  built  or  used  (e.g. 
components)  in  the  effort  to 
realize  an  implementation 


What  is  needed  is  a  means  to  assist  in  bridging  well  defined  concepts  with 
what  is  ultimately  being  implemented. 

Building  Composable  Bridges  o 


Back  To  Basics 


•  Composability 

-  A  Common  Desire! 

-  A  Significant  Need 

•  Process 

-  Best  Practices  are 
Tried  and  True 

-  Why  Ignore  it? 

•  Standards 

-  Can’t  build  quality 
products  w/  out  them! 


Building  Composable  Bridges 
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“the  ability  to  rapidly  select 
and  assemble  components 
to  construct  meaningful 
simulation  systems  to 
satisfy  specific  user 
requirements.  ” 

-  DoD  M&S  Master  Plan 


Think  of  Legos® 


Image  courtesy  Nathan  Sawaya 


4 


SimVentions 


Need  for  Bridging 


Aspects  of  Composability 

1  .Selection  and  use  of  components 
2. Construction  of  something  meaningful 

3. Satisfaction  of  specific  user  requirements 

Aspects  of  Process 

1.  Requirements 

2. Analysis 

3.  Design 

4.  Development 

5. Test 

6. Product  Deployment 


•Requirements 

•Concept 


vrwrw%  : 


Product 

Creation 


Aspects  of  Standards 

1.  Beneficial  in  achieving  interoperability 

2.  Ensuring  products  meet  certain 

-  Requirements 
-Commonality 

-  Reliability 
-TCO 

-Compatibility 


•Analysis  /  Design 
•Component  Selection  /  Use 
•Construction  /  Development 
•Test 


•Implementation 

•Interoperability 

•Something 

meaningful 
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Building  C<| 


what  we  create  truly  isn’t  satisfying  unless  it  has  met  our  requirements 


M 
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bridge  - 


“a  structure  spanning  and 
providing  passage  over  a 
gap  or  barrier.” 

“a  transitional  passage 
connecting  two  subjects  or 
movements.” 


a  means  to  span  and 
provide  a  way  to  connect  an 
idea  (i.e.,  initial  concept)  to 
something  implementable. 


• Requirements 
•Concept 
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•Implementation 
•C2/ Simulation 
Interoperability 


„  •Analysis /Design 

Sponsors, 

Architects  •Component  Selection /Use 


Developers, 
Artists, 

•Construction/ Development  Builders 
•Test 


What  we  all  want  for  any  project  is 
to  be  able  to  bridge  quickly  and 
easily  from  initial  concept  to 
implementation 


bridges  should  be  represented  and  supported  by  well-defined  conceptual 
models,  providing  an  effective  way  to  communicate  among  stakeholders 


Building  Composable  Bridges 


SimVentions 


conceptual  models  - 


•  A  means  to  understand  what  is  to  be 
represented 

•  Provides  a  quick  way  to  look  at  what  that 
product  might  be  like 

•  Like  a  blueprint 

•  Implementation  neutral 


Conceptual  Model  -  describes 
“what  the  [system  or  simulation]  will 
represent,  the  assumptions  limiting 
those  representations,  and  other 
capabilities  needed  to  satisfy  the 
user’s  requirements.  ” 

-  IEEE  1516.3  -  FEDEP 


•  C2  systems  and  simulations  can  share 
the  same  (or  similar)  conceptual  models 

•  C2  systems  may  embed  (i.e.  compose) 
simulations  to  support  its  objectives. 

-  C2/Simulation  used  for  training. 

-  Composable  bridges  supported  through 
well-defined  conceptual  models  can  be  of 
great  assistance. 


composable  bridges,  like  a  blueprint,  need  to  be  reflected  structurally  as  a 
means  to  communicate  a  concept  for  all  stakeholders 


Building  Composable  Bridges 
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Patterns 


•  What  should  we  look  for 
when  trying  to  identify  and 
define  conceptual  models? 


•  bridges  can  be  built  for  reuse 
describing  common  patterns 

-  patterns  can  be  mapped  to 
one  or  more  potential 
implementations 

-  The  goal  of  such  bridges  is 
to  help  bring  to  life 
satisfying  interoperable  C2 
systems  and  simulations 
quickly  and  easily 


Pattern  is  “an  idea  that  has  been 
useful  in  one  practical  context 
and  will  probably  be  useful  in 
others.  ”.  ” 

-  Martin  Fowler 


Pattern  “. . .  describes  a  problem 
which  occurs  over  and  over  again 
in  our  environment,  and  then 

describes  the  core  of  the  solution 
to  that  problem,  in  such  a  way 
that  you  can  use  this  solution  a 
million  times  over,  without  ever 
doing  it  the  same  way  twice.  ” 

-  Christopher  Alexander 


Design  Patous 

[Ifrmcnis  of  Keu:,il)2e 
Ob]LH.r-Ofiiaw»dl  Softwjn* 


i 


NALYSIS 

Patterns 


Reusable  Otwto  Muutis 


The 

Time  less  Way  of 
Building 


Cbrisidpher  Alexander 


“The  best  way  to  discover  a  pattern  is  to  perform  a  conceptual  analysis  on 
the  problem  space.” 

Building  Composable  Bridges  < 
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Weapon’s  Effect  Pattern 
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“It’s  often  said  that 

patterns  are 
discovered  rather 
than  invented”* 

-  Martin  Fowler 


*Fowler,  M.,  Analysis  Patterns  -  Reusable  Object  Models, 
Addison  Wesley,  1997. 


Weapon  Effects  is 
a  frequent 
"Pattern  of 
Interplay" 


Pattern  of  Interplay 


Building  Composable  Bridges 
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Jamming  /  Detection  Pattern 


Jammer 

(Originator) 


Radar 


Threat  / 
Target 


“It’s  often  said  that 

patterns  are 
discovered  rather 
than  invented”* 

-  Martin  Fowler 


*Fowler,  M.,  Analysis  Patterns  -  Reusable  Object  Models, 
Addison  Wesley,  1997. 


Building  Compo 

M 


We  could  conceivably 
use  the  " Detection " 
pattern  for  other 
purposes  besides  just 
"Jamming"  such  as 
"Vectoring 
Interceptors  " 


Pattern  of  Interplay 


Here  there  are 
actually  two 
patterns  of 
interplay 


Detection 


Jamming 
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Bridges  Built  for  Reuse  - 
Interfaces 
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•  What  should  we  look  for 
when  trying  to  identify  and 
define  conceptual  models? 


•  We  should  identify  mappable 
interfaces 


.  .it  is  essential  for  the  software 
industry's  health  that  key 
interfaces  be  well-specified  and 
publicly  available.”  -  Bjarne 
Stroustrup 


interfaces  identify 

-  what  will  be  provided 


Often  described  in  terms  of 
class  structures 


-  what  should  be  supported  , - 

by  an  implementation  •  Reflects  a  contract  of  what  is 

(hardware,  software,  or  a  ~  available  and  accessible 

system  component) 


Interfaces  provide  a  framework  to  resulting  implementations  (i.e., 
software,  simulation  or  system  components)  that  support  what’s 
described  by  a  pattern 


Building  Composable  Bridges 
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Bridges  Built  for  Reuse  - 
Interfaces  to  Components 
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•  What  should  we  look  for  when 
trying  to  identify  and  define 
conceptual  models? 


•  Components  provides  a  means 
to  satisfy  a  composable  bridge 

•  Look  for  available  components 
that  support  the  conceptual 
model. 

•  Examples 

-  Lego®  Brick  (simple) 

-  Electronic  Chips 

-  Simulation  Models 

-  Software  Components 

-  System  Components 


Components  -  “Reusable  building  blocks  which 
have  a  known  set  of  inputs  and  provide  expected 
output  behavior,  but  the  implementation  details  may 
be  hidden.  Such  components  are  useful  for 
constructing  simulations  and/or  providing 
functionality  for  simulation  systems.  ”  -  COI  M&S 
Metadata  Focus  Group 


A  component  provides  a  means  to  satisfy  a  composable  bridge 


Building  Composable  Bridges 
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Bridges  Built  for  Reuse  - 
Discovery  Metadata 
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What  should  we  look  for  when 
trying  to  identify  and  define 
conceptual  models? 

Need  to  ensure  the  discovery  of 
useful  components,  interfaces 
and  patterns 

Discovery  metadata  provides 
way  to  catalog  /  tag  reusable 
assets 

Helps  optimize  composability 
and  reuse 


Metadata  is  “structured,  encoded  data  that 
de-scribe  characteristics  of  information¬ 
bearing  entities  to  aid  in  the  identification, 
discovery,  assessment,  and  management  of 
the  described  entities  [2].  ” 
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V\fe  want  and  need  to  use  metadata  to  catalog  patterns,  interfaces  and  components. 
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Enabling  Technology  Standard  for  Composable  Bridges 


Buil< 
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What  common 
structure  allows  us 
to  represent 
composable  bridges 
for  supporting  C2 
system  and 
simulation 
interoperability? 


COMPOSABLE 

BRIDGES 


Metadata 


Patterns 


Interfaces 


Cornponents 


Components 


Components 


Components 


Components 


Components 


Implementation 

Space 

Simulations  /  ^ 

C2  System  ^ 
Applications  ^ 

Interoperability 

Space 


C2/Sim 

Interoperability 
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Enabling  Technology  Standard  for  Composable  Bridges 


BOM 

Base  Object  Model 


ISO 


Model  Identification 


( 


Notes 


Building  Composable  Bridges 


Conceptual  Model 

Pattern  Of  Interplay 

State  Machine 

Entity  Type 

Event  Type 

Model  Mapping 

Entity  Type  Mapping 

Event  Type  Mapping 

Object  Model  Definition 

Object  Classes 

Interaction  Classes 

Data  Types 

[  Lexicon  (definitions)  | 


BOM  is  “a  piece  part  of  a 
conceptual  model, 
simulation  object  model,  or 
federation  object  model, 
which  can  be  used  as  a 
building  block  in  the 
development  and/or 
extension  of  a  simulation  or 
federation.  ”[3] 


Desired  Characteristics: 

-Identifies  and  names 
the  common  problems 
in  a  field  of  interest, 

-Describes  the  key 
characteristics  of 
effective  solutions  for 
meeting  some  stated 
goal, 

-Helps  the  designer 
move  from  problem  to 
problem  in  a  logical 
way,  and 

-Allows  for  many 
different  paths  through 
the  design  process. 


-  Based  on  ideas  from  Christopher 
Alexander 
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Using  the  BOM  as  a  Bridge  to  Achieve 
Interoperability 


Conceptual 
Space 


Implementation 
Space 


BOMs 


Building  Composable  Bridges 
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Using  the  BOM 
Interoperability 
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as  a  Bridge  to  Achieve 


BOMs 

•  help  to  focus  on: 

•  what  needs  to  be  shared 
conceptually  within  an  C2  / 

M&S  environment, 

•  how  the  intended  “components” 
are  to  perform  pragmatically, 

•  how  qualifying  interfaces  are 
semantically  defined,  and 

•  how  such  components  are 
syntactically  structured 

•  complements  the  use  of  other 
interoperability  standards  in  an 
independent  way 

(e.g.,  HLA  /  TENA) 


Implementation 
Space 


b/e  BOMs 


ftware 


components, 
object  models) 


Building  Composable  Bridges 
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Levels  of 
In  teroperability 
(technical,  syntactic, 
semantic,  pragmatic, 
dynamic^  conceptual)^ 

Achieving  Level  6  Conceptual  Interoperability 

•  Ensures  greater  likelihood  of  success  for 
other  levels  of  interoperability. 

•  Requires  a  “fully  specified,  but 
implementation  independent  model.” 

-  Paul  Davis 


Using  the  BOM  as 
Interoperability 
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a  Bridge  to  Achieve 


•  BOMs  support  stitching  of 

-  Conceptual  models,  and  the 

-  Structural  elements  offered  by 
Object  Models 

•  Results  in 

-  Mappings 

-  BOM  Assembly 

•  BOMs  /  BOM  Assembly  can 
represent  different  architecture 
implementations 

•  provides  a  powerful  construct 
for  building  composable  bridges 
and  achieving  interoperability 


Builc 

fl  ft 

“the  abstract  things  described  in  a  Conceptual  Model  (entities  and  events)  can  be  mapped  to 
the  actual  types  of  things  we  are  modeling  (representing),  which  are  described  in  the  Object 
Model  Definition  of  a  BOM.  So,  if  1  identify  that  there  is  a  firing  entity  at  the  conceptual  level 
(in  the  conceptual  model),  my  mapping  tells  me  what  system  architecture  classes  [HLA, 

TEN  A,  Navy  OA  or  otherwise]  can  fulfill  the  entities  and  events  associated  to  it.” 
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Topics  Covered 


Problem 
Back  To  Basics 
Need  for  Bridging 

-  Aspects  of  Composability 

-  Aspects  of  Process 

-  Aspects  of  Standards 
Definitions 

-  Bridge 

-  Conceptual  models 
Bridges  Built  for  Reuse 

-  Patterns 

-  Interfaces 

-  Components 

-  Discovery  Metadata 
Enabling  Technology  Standard  for 
Using  BOM  as  a  Bridge  to  Achieve 
Summary 


Building  interoperable  C2  systems  and 
simulations  is  arduous 


Composability  -  Common  Desire  /  Need 
Process  -  Requirements  First! 
Standards  -  Ensuring  products  meet 
Requirements  and  are  compatible 


•Requirements 

•Concept 
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BRIDGE -“spans/ 
connects  an  idea  (i.e., 
concept)  to  something 
implementable” 


CONCEPTUAL  MODEL - 
A  means  to  understand  what 
is  to  be  represented 


Composable  Bridges 
Interoperability 


Building  Composable  Bridges 


BOM 

Bgse  Object  Mo4el 


COMPOSABLE 

BRIDGES 


Metadata 


Patterns 


Q. 

Q_ 

03 


Interfaces 
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Summary 


Interoperability  is  best  addressed 
through  "composability" 

Composability  can  be  understood  and 
carried  forward  through  the  use  of 
"bridges" 

Bridges 

-  “span  and  provide  a  way  to 
connect  an  idea  (i.e.,  concept)  to 
something  implementable” 

-  should  be  represented  and 
supported  by  well-defined 
conceptual  models 

•  Patterns, 

•  Interfaces, 

•  Metadata 

BOM  offers  key  standard  for 
supporting  composable  bridges  & 
achieving  conceptual 
interoperability 


Implementation 
Space 

bridge / 

/  BOMs 


Conceptual 

Space 


- ^Interoperable 

conceptual  Space 

interoperability 


BOM 

•  helps  identify  a  neutral  way  to  characterize 
C2  capabilities  and  simulation  capabilities. 

•  facilitates  communication  among 
stakeholders 

•  helps  realize  implementation  /  interoperability 
needs  for  C2  systems  and  simulations 


Building  C 


w 


The  clarity  provided  by  a  conceptual  model  is  what  helps  bring  a  concept 
to  implementation  to  a  potential  state  of  interoperability. 
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Discussion  /  Questions? 


SimVentions 


•  Tools 

•  Shared  Experiences 

•  More  Info 

-www.boms.info 
-  www.sisostds.org 


Contact  info: 

Paul  Gustavson 
pgustavson@simventions.com 


Building  Composable  Bridges 
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Backup  Slides 
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BOM  Experiences 


form 


S' 


B 

AiH 
made 
sir  ^ 

<f  rS 

AcA 


BOM  1 


EfiL 


>>oj 

fS  fr  ^ 


BOM  2 


_  . 
Examr 

BOMs 


SOM  3 


<?-eV  I  and 


/ei®  originally 


To  date  BOMs  developed  for  the  Army,  Navy,  Air  Force,  Missile 
Defense  Agency,  and  general  simulation  community 

Example:  Real-time  Platform  Reference  (RPR)  BOMs  -  S/SO 

Example:  Airborne  Electronic  Attack  (AEA)  BOMs  -  JHU/APL 

BOMs  A  eloped  from  the  collection  of  DoDAF  vf 
HU/APL  architecture  team. 

\Jify  mission  objectives 

ceptu-  'e  prodded  hv  such 
3  co  J  repij 
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sen 
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Federate  B 
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Range 
BOM 
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wii.  o0<^  very  short  period  of  time 
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Model 

#1 

Model 

#2 

Model 

#3 

Model 

#n 
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nitrated 


CD 

CD 
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Q  MPBAM 
- 


a- 


□ 


Model  Identification 
Primary  author 
Conceptual  Model 

Patterns  Of  Interplay 
MPBAMActivities 
Launch 
Ignite 
Burn 
Coast 

IdentifyTarget 
Maneuver 
Hit 

ip)  State  Machines 
-  -(®i  5tdDiehlPGMMT rajectory  5M 
InitialState 
BallisticClimbout 
AerodynamicCruise 
TargetPitchover 
TerminalCruise 
Complete 
Entity  Types 
Projectile 
Target 
Launcher 
Operator 
©  Event  Types 
Model  Mapping 
Object  Model  Definition 
©  Notes 
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Levels  of  Interoperability 


Level  6  -  achieved  when  the  anticipated  capability  that 
is  to  be  provided  by  the  models  and  simulations  to  be 
used  are  fully  understood  and  agreed  upon  by  all  the 
stakeholders.  At  this  level  of  interoperability  there  is  no 
ambiguity  in  what  is  expected  to  be  shared. 

Level  5  -  achieved  when  systems  are  able  to  come  “on¬ 
line”  and  begin  to  exchange  and  reflect  data  with  other 
systems.  Such  systems  are  “able  to  comprehend  the 
state  changes  that  occur  in  the  assumptions  and 
constraints  that  each  is  making  over  time,  and  they  are 
able  to  take  advantage  of  those  changes.”[7] 

Level  4  -  achieved  when  the  systems,  simulations  or 
applications  involved  in  the  exchange  of  data  are  aware 
of  the  specific  methods  and/or  procedures  that  a  calling 
system  is  requesting. 

Level  3  -  achieved  when  a  common  reference  model 
(i.e.,  definition  set)  is  used  to  perpetuate  the 
understanding  of  the  level  2  data  being  shared. 


Modeling  S 
Absfractbon 


J5P 3 


Wfltwpirk  f 
Conrttctfcuky 


Level  5 

Dynamic  Interoperability 


Level  4 

Pragmatic  interoperability 


Level  3 

Semantic  Interoperability 


Level  2 

Syntactic  Interoperability 


Level  1 

Technical  Interoperability 


Level  0 

No  Interoperability 


Level  2  -  achieved  using  technology  such  as  XML, 
which  offers  a  means  to  define  and  use  a  common  data 
structure  among  the  systems  established  in  a  network. 

Level  1  -  requires  an  agreed  upon  communication 
technology  infrastructure  and  protocols  such  as  UDP  or 
TCP/IP  to  support  the  handshaking  among  networked 
systems. 


Building  Composable  Bridges 
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Achieving  Level  6  Conceptual  Interoperability 

•  Ensures  greater  likelihood  of  success  for 
other  levels  of  interoperability. 

•  Requires  a  “fully  specified,  but  R 

implementation  independent  model.” 

-  Paul  Davis 
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Background  -  BOM  Early  Adopters 
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210+  users  representing  18+  countries  H 


Available  Tool  -  BOMworks 


Create  BOMs 
Edit  BOMs 

-  Grid/XML/UML 

-  Cut/Copy/ 
Paste 

Validate  BOMs 

Source  Code 
Generation 

Import  FOMs 

Built  on  Galileo 
Framework  - 
extensible  and 
customizable 


BOMworks  Community  Edition 


File  Edit  Tools  Help 


j  &  y 


Tree  View  | 


D  Execute AEA Mission 

+i  |©  Model  Identification 

B-®  Conceptual  Model 
S)  ®  Model  Mapping 
B-W  Object  Model  Definition 
L  H  Notes 


Design  View  Text  View 


(^Conduct_I5Fy 


iLLl0  o 


□  '  "a  X 


%  e  y 


Property  View  Resource  Palette 

B  Model  Identific. . . 

name  Execute_AEA_Mis . . , 

type  BOM 

version  0. 1 

modificationDate  5/16/07 
securityClassification  Unclassified 
purpose  AEA 

applicationDomain 


Free 

download  is 
available 


Object  Class  Diagram  Interaction  Class  Diagram  Notes  Diagram  Activity  Diagram 

Dependency  Diagram  Sequence  Diagram  State  Diagram  Event  Diagram  Entity  Diagram  Use  Case  Diagram 
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id  notes 
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SimVentions 


BOM  Conceptual  Model 


j  Model  Identification  (Metadata) 


Bi 


Conceptual  Model  Definition 


Pattern  of  Interplay 


State  Machine 


Entity  Type 


Event  Type 


Model  Mapping 
Entity  Type  Mapping 


Event  Type  Mapping 


Object  Model  Interface 


Object  Classes 
[  HLA  Object  Classes 
|  HLA  Object  Class  Attributes 


|  HLA  Data  Types 


o 


CONCEPTUAL  MODEL  -  Describes  what  is  to  be 
represented,  the  assumptions  limiting  those  representations, 
and  other  capabilities  needed  to  satisfy  the  user’s 
requirements.” 


PATTERN  OF INTERBL  4Y-=uUzehavior  pattern  characterized 


hy  n  s&pience  o 
conceptual  entities 


MTERPL  A Y  -  o  behavk 
(pattern  actionsjhvo 


\  voiving  one  or  more 


PATTERN  ACTION  -  A  single  sfepHna  pattern  of  interplay. 
Can  be  supportedjxy  a^afmedievent  pr  by  another  BOM. 
May  result  in  cCstate  change  'bf^cTconcep tua!  entity. 


STA  TE  MACHINE  -  A  description  of  the  various  states  or 
conditions  of  a  conceptual  entity,  and  how  the  pattern 
actions  associated  with  one  or  more  patterns  of_  interplay  may 
affect  these  conditions  over  the  conceptual  entity's  life. 

CONCEPTUAL  ENTITY  -  An  abstract  representation  of  a 
real  world  entity,  phenomenon,  process,  or  system.  . 


CONCEPTUAL  EVENT  -  A  representation  of  a  transient 
action  that  occurs  among  conceptual  entities  that  may  affect 
the  state  of  one  or  more  of  the  conceptual  entities. 
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Key  Concepts 


SimVentions 


•  Composabilitv  -  Ability  to  assemble  things  from  components 


Buil 


it 


“Modularity  is  necessary  when  dealing  with 
complex  systems,  and  some  degree  of 
composability  is  surely  possible  and 
desirable.  ” 

-  Paul  Davis  (RAND) 


UNDERSTAND!  NG  COMPOSABI LITY 

•  Creating  a  simulation  requires  breaking  the  problem 
into  parts  that  can  be  addressed  separately 

-  To  reduce  the  effects  of  interruption 

-  To  permit  specialization 

-  To  facilitate  computing  alternative  ways  of  handling  a  given 
component 

-  To  maintain  the  software  over  time 

-  To  reduce  risk  by  relying  upon  previously  proven 
components  where  possible 

•  Understanding  complex  systems  requires 
decomposition. 

-  No  one  can  comprehend  the  whole’s  details 

•  Testing  systems  is  simplified  if  done  module  by  module 
then  at  the  system  level 

•  Controlling  costs  /  economic  incentives 

-  Costs  are  correlated  with  the  amount  of  new  code  writing 

•  Maintaining  and  modifying  is  easier  /  safer 

-  Individual  modules  can  be  substantively  modified  or 
updated  as  software  as  necessary,  without  endangering 
the  overall  system. 


